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iBSTMCT 


A project was started at the IH Kanpur Computer Centre 
in 1978 to link up DEC-1090, TDC-5I6 and IBM-1800 in a star 
configuration using a MICRO-78 as the central switch* 3h the 
first phase of the work, hardware interfaces were designed for 
these machines (except the interfaces for the MICRO to DEC 
link). In the second phase, i.e., the current one, the hard- 
ware interfaces for the MICRO to DEC link hawe been designedf 
certain changes hatfe been made in the earlier interfaces and a 
part of the software has been implemented on MICRQ-78 and 
IBM-1800* This thesis describes the design of the hardware 
interfaces for the MICRO to DEC link and the software imple- 
mentation on MICRQ-78 « 
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CHAPTER 1 


INTRODUCTION 

A computer network is a configuration in which two or more 
computer systems are interconnected for communication among them- 
selves* Such a configuration has many applications, some of which 
ace resource sharing,, remote job entry, and load sharing* Com- 
puter networks started caning up in late 60 r s and today we have 
got many large networks in the world, a few examples being ARP A, 

TIMET, CYCLADES, SIT A, ALOHA, PRESTEL ana SWIFT. In India, ’ * 
this field is still in its infant, but of Lite considerable interest 
has been shown to develop networks in India and one suc^s attempt 
has been made at the I IT Kanpur Computer Centre* This thesis des- 
cribes one phase of the work in developing an experimental oomputer 
network at IIT Kanpur. 

1-1. iit/kadpijr COMPUTER Mg 

The IIT/k network will link up IEC-1 090, TDC-31 6 and IBM-1800 
in a star configuration using a MICRO-78 as the central switch* 

The configuration along with the hardware required to interface 
them is shown in Figure 1-1. The hardware interfaces 1 ,2, 3,4,5 ,8, 9, 

10 and 11 shown in this figure have already been built (Ref. 1 

* 

for 1,2, 3,4, and 5» Ref* 5 for 8,9f and Ref* 6 for 10,11) and in 
th*e present phase of work interfaces 6 and 7 have been designed* These 
interfaces are on the MICRO-78 side of the MICRO to DEC link. The 
counterpart of this hardware interface on IE C-system 10 is called ■ 

DQ 11 (Ref. 3)* 






The work done in the present phase also includes making 
some changes in the earlier hardware interfaces and implement- 
ing a part of tho network software on IBM-1800 and MICRO-78. 

The network software has been designed according to the DEC 
specifications since the DEC-systen provides comprehensive network 
facilities. Following is a brief description of the digital 
network architecture. 

1-2. DIGITAL NETWORK, ARCHITECTURE 

DIGITAL provide networking facilities for their computers 
and the family of products that create this network is called 
DECIET. All implementations of DECHET adhere to a cannon network 
architecture that defines the structure and protocols used to 
communicate through the network. This architecture provides a modular 
design for DECNET and has three distinct layers* 

(i) 'The Physical Link Control Layer 

(ii) The Network Servioe Layer 

(iii) The Application Layer. 

Each layer has got some well defined functions and is related 
to layer above it. Following ia a brief description of those layers! 

(i) The Physical Link Control Laver ? This is the lowest layer 
and lies immediately above the physical, transmission of bits over the 
data link. The functions of this layer are performed by the Digital* 
Data Communications Message Protocol (DDCMP). This protocol i3 
responsible for the correct sequencing and integrity of the data 
transmitted over a physical link. 




(ii) The Network Services Laver t This layer performs. the 


following fe.nct ions: 

(a) Routing the messages between source and destination 
nodes* 

(b) Managing logical data channels, i.e., establishing 
logical communication links between different pro- 
cesses (e.g., user programs) so that they can ex- 
change inf ormation regardless of their physical 
locations within the network. 

The pcotocl which pe forms these functions is called Network 
Services Protocol (NSP) • 

(iii) The Application layer ? The functions of this layer are 
performed by the Data Access Protocol (DAP) which is a user level 
protocol. Its primary purpose is to permit remote file access 
within the DECNET environment independently of the i/o structure 
of the operating system, being accessed* 

In the currant phase of work, only the first layer (DDGMP) 
has been implemented on IBM-1 800 and MIGRO-78* 

1-3. 0T/ER7IEI7 OF THE! THESIS 

Chapter 2 describes in detail the design of hardware inter- 
faces for the MICRO to DEO link. In Chapter 3 » DDCMP has been 
described in detail and in Chapter 4 its implementation on MECRD-78 
has been discussed. Conclusions are given in the last chapter. 





CHAPTER 2 


MICRO-78 HARDY/ARE UEERFACEES FOR THE DEC-10 LINK 

In this chapter, we discuss the design of the MICRO-78 
Hardware Interface for the DEC-systen-1 0 link* is explained 
in Chapter 1 , the counterpart of this interface on the DEC-1 0 
is the DQ.-11 Synchronous Interface on the DM87S Front-end Processor* 
The design of the MICRO-78 hardware interface for this link has 
"been influenced by 

(i) The line protocol used hy DQ.-1 1 , and 

(ii) The line protocol that is used on the MICRO-78 

to TDC-31 6 link or on the MICRO-78 to IBM-1800 link* 

The strategy in designing this hardware interface has been 
to make the minimum possible changes in the already designed inter- 
faces on MICRO-78, for ‘ the links to the TDC-31 6 and IBM-1800 

(these two interfaces are identical). The advantage of designing 

t*- 

by this str^y is that to can use the same printed circuit boards 
as are used for MICRO-78 to TDC-316 link (or MICRO-78 to IBM-1800 
link) with minor changes on them. 

Figure 2-1 shows the basic block diagram of the hardware 
configuration for the DEC-10 link. As shown in the figure, 
there is a control card which acts as the interface between the 
MICRO-78 system and the sending and receiving interfaces. The 
control card has various functions to perform which ace described 
in Ref. 1, Sec. 4-2. 




Fig* t.| 





2-1 . SEKDBTG INTERFACE 


The Sending Interface has two addressable registers* One 
register holds the control and status information and is called 
control and status register (CSR). The other is the data register 
(DTRG) which contains the data loaded by CPU to be transmitted 
serially on the serial data line. 

The sending imferfaco actions can be summarised as follows s 

(1 ) With power on, the CSR bits are cleared, and the 
sending interface transmits SOT characters (226 q) 
over the line (this is the idling state). 

(2) Processor deposits the first byte of the message to 
be transmitted in DTRG and sets flags for the initia- 
tion of the eb ssage (HOT) and byte handed, ovor (TK ) 
in the CSR. 

(3) At the end of current byte transmission, the interface 
checks if at least one SOT has been sent after the 
last massage was transmitted* If so it loads DTRG 
contents into the parallel to serial converter register 
(TXRG-) whose contents can be shifted out on the line, 

XSB first. 

( 4 ) As soon as data is transferred from DTRG to TXRG an 
interrupt is generated. The CPU transfers the next byte 
onto DTRG. 

( 5 ) With the interrupt request following the last byte 
transmission, the CPU resets CSR bits thereby causing SI 
to go back to Step 1 after the current (last) byte has 
been transmitted. 



o 


2-1 *1 Hardware Description of the Si t The CSR is a 5 "bit 
register implemented using D flip flops (2 x 7474)* The GSR 
format is as shown in Figure 2-2. The SI protocol in HDL (hardware 
description language) is as follows* 

Definitions* 

Register : DTRG (0-7), CSR (0-7), LC 
Shift Register * TXRG (0-7) 

Clock PP 

Character SIR (226 in octal). 


/(Sit + mods') . (ic=o) . pp/txrg<~ sot, mode 1 (si) 

/(LC / 0) . pp/shift right ERG, decrement LC (S2) 

/UTIT . MODE (LC = 0) . PP/TXRG <— DTRG, TX<— 0 (interrupts (S?) 

processor) 

/iHIT . MODE . EC . (LO - 0) . EP/ebR <-1 (S 4 ) 

A«M + DTRG / PRESET TX (S5) 


(Rote * vTXM and DTRG follow negative logic. Thus S5 is equivalent 
to saying that DTRG has to he written into by the PC). 

The expressions enclosed in / / define various combinations 

of the CSR hits and other conditions. The action following it is the| 

action to he taken when such condition is satisfied* SI, S2, etc., 

are the control signal numbers which correspond to these o end it ions • 

2-1 .2 Explanation of CSR Bits * The CSR bits as depicted in Figurj 

2-2 have the following significances 

(i) MIT * The initialization hit. It is set hy processor to 

indicate that a message is ready to he transmitted* It is reset 

when the last hyte has been transmitted. 



(2) MOBS * This is set "by interface to Indicate that at 
least one SIS has been transmitted* It is reset at the end 
of message transmission by PC to enable the transmission of 

at least one SXtT character over the line before the next message 
starts* 

( 3 ) EC* This is the bit which keeps track of bytes as they 
are handed over to the SI by the processor* The sending interface 
sets it when a byte is dump*C into the DTHG by the processor and 
resets it when the byi;e has been transferred to TXRG. 

(4) IHTF * Interrupt flag. This is set whenever IRIT is set 

and TX is reset, indicating an interrupt condition • Getting of this 
generates an interrupt and this flag is used to indicate to the 
processor the nature of the interrupt. 

(5) ERR ? If with the previous byte transfer TX was reset 

and the interrupt thus generated was not serviced by the PC in time, 
then the TX would remain reset at the end of the current LC = 0 cycle 
This means that the DTRG contents am the s ane as the old value since 
new byte has been deposited into it* This is an error condition 
causing retransmission of a byte and is indicated by this bit. It 
is reset by PC* 

2—1 .3 SI Block Diagrams (Figure 2-3) * Hie SI hardware consists j 

■ i 

of the following functional blocks* 

i a) Clock generator 

b) Data register and parallel to serial converter 

c) Control signals 

d) Line driver 

e) CSR • 
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The following is a brief description of these blocks* 

(a) Clock Generator (Figure 2-4(a))» The clock generator 

uses a 2 MHz costal* Motorola's IMJ75 generates the basic clock | 

which is divided down by a chain of 7490's and a 7474 (Figure 2-4(b)) 
to get a 10 KHz clock and this clock is called PP* 

(b) lata Register and Parallel to Serial Converter (Figure 2-5) 5 
The DTRG outputs and. the strip switoh with SYH combination 

f 

terminate on the multiplexor, except when SJ is active, SHI combina- ; 
tion is selected* Multiplexer output goes to the TXRG input. As | 

per the hardware algorithm, TXRG is to be loaded whenever 
is- active. PP doe3 the shifting out. To avoid ambiguity in loading 
data, S.j + should be slightly delayed as compared to the switoh 
over leading edge of S^* This goal is easily accomplished since 
an extra gate is needed for deriving (Figure 2-5 (b)). 

(o) Control Signals (Figure 2-6 )$ Control signals are all low- 
active since the signals to set/reset 7474* s are to be low signals* 

The generation of control signals is self explanatory * 

(d) line Driver (Figure 2-5 (b))* The DQ.11 specifications require 
the data on serial input line to be of EIA specifications* For this 
purpose TTL/eIA converter is used* 

(a) The CSR Controls (Figure 2-7) : CPU communication with CSR 
is similar to that discussed for DTRG. Note in the figure that all 
the clear inputs except that af TX bit are directly connected to 
master clear (MC) of the MICRO-78, while the TE bit is cleared by MC + S 
This facilitates the clearing of all bits when the MICE0-78is started 
up (or MG switch on the console of MICRO-78 is pushed)* TX b^;is 
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cleared "by the interface in every byte transfer i.e .» when 
is present or it can be cleared by the MC« 

(f) Line Counter LG (Figure 2-8) : Any action by the interface 
occurs at LC = 0 points. Every tine a count is completed, the 
ripple clock output causes the count of 8 to be loaded in the 74190 
and then the count down starts. This serves to nark out the 8-bit 
periods by giving out Max/Min output which is used as LC ® 0 pulse. 

(g) Interrupt Generation (Figure 2-9) s whenever the INTF is set 

i 

an interrupt request is to be transmitted to the control card priority j 
encoder circuit. The priority encoding and servicing of the interrupt j 
is described in Ref. 1 Sec. 4-2. 

(h) Transmission of System Clock (Figure 2-3): The system 
clock is transmitted by the sending interface along with tho data 
to DQ,11 external clock input. The clock must conform to ELL speci- 
fications and for this purpose TTL/eIA converter is used in the 
same way as used in transmitting data. 

2-2. BECEIVING INTERFAGB 

The receiving interface has the following functions * 

(i) To mark out byte boundaries by detecting a SYET character 
over the line (byte synchronization). 

(ii) To detect S6M in the idle and byte synchronized state and 
generate an interrupt. 

(iii) To interrupt PC every time byte is handed over to the DTRG 
in the message reception mode. 

(iv) To set a flag indicating over-run, if any interrupt request 


is not serviced in tine 







Pifi.!-*: LINE COUNTER 





Inputs to the receiving interface are: 

(i) Serial data on the line, which conforms to EIA standards* 

This data is converted to TIL specifications using EIA/TTL converter 
as shown in Figure 2-10. 

(ii) The system clock which is transmitted from the DQ11 and 
is also EIA specified is converted to TTL specification using EI/j/tH- 
converter as shown in Figure 2-10. This clock will be referred to as 
PP or the system clock* 

2-2-1 Hardware Description of li t Just as the sending interface, 
the receiving interface also has got two addressable registers, the 
DTRG and the OSH. The overall block diagram is shown in Figure 2-10 
CSR format is shown in Figure 2-11 * 

2-2*2 Description of the Receiver OSR t 

(1 ) Modet This is set by the interface to indicate that a 
non SYR character has been received in the idle mode* It is reset 
by the processor* 

(2) EX (Byte handover flag)* It is set by the interface when a 
byte has been received and handed over to the DTBG* It is reset by 
the interface when PC has read the DTRG* 

(3) IHTF (interrupt Flag): It is set when Mode and RX flags are 
set. This causes an interrupt request to be generated* This flag is 
reset when the interrupt has been serviced by the PC* 

(4) OVR (Overrun Flag): This flag is set by the interface to 
indicate an overfun condition. This is cleared by the PC* 
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(5) BF (Byte Synchronization Flag): It is set "by the inter- 
face when a SIN is recognized for the first tine after the node bit 
has been reset* It is reset by the processor tinder various conditions 
such ass 

(i) The first byte of the message is not one of SOH (226g), 

ENQ, (005g) or LLE (220 Q ). 

(ii) A message has been completely received, or 

(iii) Any other reason governed by the software protocol. 

The hardware algorithm for the receiving interface is as followss 


/SF . PP/ if R X RG = SIN then SF<~ 1 , LG » 8 (SI ) 

/PP/ Shift right BXRG, BXR&(8) bit from line 5 (S2) 

decrement LC 

/sf . mm . (LC=0) . PP / if RXRG / SIN then (S3) 

. MOBS <.* 1, DTRG <— IiXBG, HX<-1 

/SF . MOTE . (LC = 0) . BX . PP/dTRG BXEG, EX<~1 (S 4) 

/SF . MOTS • (LC - 0) . BX * PP/ 0VP<-1 ' (S5) 

/TSEM + DTEG-/ Clear EX (S6) 


(Notes TSRM and DTEG follow negative logic and S6 is equivalent 
to saying that tho TTRG has been read by the PC). 

BXBG is the serial to parallel converter shift register that 

receives the serial data from the EIA /TTL converter, I»C is the 

line counter. vThen SF is set, LC is initialized to 8 and for every 

dtb sequent LC = 0 tob it is loaded with 8. Thus once set, subsequent 

LC ® 0 would mark out the byte boundaries* 

2-2*3 BX Interface Block Diagrams ; The hardware consists of 


following functional blocks* 



(a) Data register and ser ial/ par alls 1 converter. 

(b) Data SHI detector. 

(c) Control Signal Generator 

(d) CSR control. 

The following is a brief explanation of those blocks* 

(a) Data Register (DTRG) and the Serial/parallel Converter 
(RXBG-) (Figure 2-12) » Serial data from EIA/tTD converter gets clocked 
into the RXG.G so that at the end of 8 system clocks one byte of data 

is in the RXRG-* The data is transferred into the DTRG whenever S-. 

;5 

or S^ is active. 

(b) SYR Detector (Figure 2-1 3) s Three 3-line to 8-line de- 
multiplexors arc used for this purpose. The RXRG- outputs are 
connected to the inputs of the demltiplexers as shown. A is the DSB. 
The output of the detocto® is low whenever a SYR combination is 
present at the ItXRG. 

(c) Control Signal Generator (Figure 2-1 4): The control 
signal generation with the help of hardware description and Figure 2-1 
is self-explanatory. 

(d) CSR Control (Figure 2-1 5)* The CSR design philosophy is 
the same as in the sending interface and the CSR is accessible to 
the PC via the 3-state buffers. 

(0) Interrupt Generation (Figure 2-1 6)* The IMF flag is set by 
the interface to interrupt the PC* The IRTF flag goes to the control 
card and an interrupt request is sent to the PC via the priority 
encoder circuit (discussed in Ref • 1, Section 4-2) . The IMF flagf 1 ' 
is reset by the processor. 
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CHAPTER 3 

DESCRIPTION OP DDCMP 


In Chapter 1 (Sec. 1-2), the Digital Network Architecture 
(MTA) was discussed and it was mentioned that DDCMP forms the 
lowest lqyer, i.e., the physical link control layer of the DNA* 
The main function of DDCMP is to ensure correct sequencing and 
integrity of the data transmitted over a physical link. This 
chapter discusses DDCMP in detail. 

Please note that - 

(i) The term ’m^Jsage’ used throughout is the same as the 
term ‘packet’ used in common literature. 

(ii) Although DDCMP caters for "both synchronous and asyn- 
chronous lines, we shall describe here only the portion suitable 
for synchronous links. 


3-1. MESSAGE FOMATS 

In DDCMP, we have three kinds of messages - 

(i) Data Messages 
(ii) Oontrol Messages 

(iii) Maintenance Messages 

Every data message carries a number (from 0 to 255) with it 
to enable correct sequencing at the receiving end. The numbering 
begins with number 1 after initialization (the. details of initia- 
lization are described in Section 3-5) is incremented by one 
(modulo 256) for each subsequent data message. Hie receiving statical 
acknowledges the correct receipt of data messages by sending an ACK 
(a control message) or by sending this information along with a data 
message going towards thab station (a piggybacked A£3C). The 



.35 

acknowladgement cables a uumboa? *n* which indicatos connect 
secepbioi* of all messages upto <& including data message number 
x n x • If an acknowledgement is not received within a contain 
time, a timeout is said to have oecunned and a contnol massage 
HEP is sent to ang uin e about the status of the sent data message# 

Be pity to EBP is either an ACK or a NAK (negative acknowledgement ) . 

A NAK (another control message) is sent when a massage in error 
is detected. STBT and STACK are two other control messages and 
are used, for initialization of the protocol. Maintenance 
messages are used for diagnostic testing* "bootstrapping* dumping 
and other such functions. 

Now we proceed to describe the message formats in detail. 

.1 Data Messages : The format of a data message is shown 
in Figure 3**1 (a) 

(1) m- (■> tyte) (Start of Header): This field contains 
the number 1 29(201 g) and it identifies a data message. 

(2) COIJffl? (14 "bits): This field specifies the number of 
bytes in the data field. The value ‘0* is not allowed. 

(3) Flags (2 bits) 

(i) Bit Q : The quick sync flag (Q, SYNC flag): 'When 
this fl^j is on* it indicates to the receiver that 
the next message will not be contiguous to this one 
a n d resynchronization should follow this message. 

The function of this flag will be described in 
detail in Section J-2»1 * 
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(ii) Bit 1 : The SELECT flag* This is used to control 
txansniss ion ownership on multipoint and half 
duplex links. In our implene n t at ion since to have 
only- full duplex point to point lines, to will, not • 
he concerned with this flag* 

Note: COUNT and FLUS fora a 2 -byte quantity. The first byte 
contains the 8 low-order bits of COUNT. The second byte contains 
the SEIEGT flag in the most significant bit, the QSINC flag in 
the next bit and th6 6 higher-order bits of COUNT in the remaining 
6 bits* 

(4) EESP (l byte) : This is the piggybacked ACK field and 
carries the number of the last ccnsequtivo correct message received 
from the other end by the station transmitting this message* It 
implies that all unacknowledged, messages between the one acknow- 
ledged in the last KESP field and the one acknowledged by this EESP 
field (modulo 256) have been received correctly. 

(5) NUM (l byte) : This field carries the number of this 
data message* 

(6) ADDR (1 byte) : This is of.relevance only on multipoint links 
and carries the address of the tributary stations on multipoint links* 
This field is of no conoern to our implementation. 

(7) BIKCK1 (2 bytes) : ‘These 2 bytes carry the block check on 

1 ^ 15 2 

the header (SOM through ADDR) using the CSC-1 6 polynomial x +x J +x +1 . 

15 

The block check, is transmitted x bit first* On re ceopfcicn the CRC 
computation should yield a zero remainder if no errors oxist* 

(8) BataO'CQUM? 11 No* of Bytes) * This is the data field and 
carries as many bytes as specified in the COUNT field* This field, 
is totally transparent to the protocol and. has no restrictions on 



bit . patterns, groupings or interpretations. 

(9) BLECK2 (2 bytes ) t This field contains the block check 
on the data using the same -polynomial as for BIKCK1 . 

3-1 »2 Control Messages } There ore 5 types of control messages* 
ACK, NIK, EEP, STEP and STACK. We shall describe them one by one* 

(l ) AGK i As already mentioned, ACK message acknowledges the 
correct receipt of data messages. It conveys the same information as 
the EESP field in a data message and i3 used when acknowledgements 
are required but there is no data message to be sent in the reverse 
direction. Its format is shown in Figure J-l (b). 

(1 ) ENQ, (l byte) * This field is the identifier of a control 
message and has value 005* 

(2) ACKTYPE (l byte) i This identifies tho type ACK and has 
value 1 . 

(3) ACKSUB (6 bits) ; Tiiis field has a value of *0* . 

(4) FLICS (2 bits) : These flags are the QSYNC and SELECT flags 
and have the same function as in data messages. 

(5) EES? (l byte) * This field has the same function as the EESP 
field of data messages. 

(6) FILL (1 byte) * This byte has value *0* • 

(7) ADDS (l b.vte) t Same as the AIDE field of data messages. 

(8) BLKCK5 (2 bytes) * Block check on the control message (on 
EHQ, through ADDB) . Similar to BLECK1 for a data message. 

(ii) HAK (Negative Acknowledgement 1 ) } This message is sent to* 

ru 

the other end when an erroneous message is received from that 3 ids ■**. 
The reason for error is also sent. It also includes the same 
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information as carried by an ACK message and thereby serves two 
functions* acknowledging previously received correct messages and 
notifying some error condition. The format for this message is 
shown in Figure 3-1(0). The ENQ, FLiGS, FILL, ADDS and BIKCK3 
fields are the same as in an ACK message . 

(l) The field NAKTYPE (l byte): indicates the type HA K and 


has a value of 2. 

(2) The field SEASON (6 bits) identifies the source and reason 
for error. 

The various values and the corresponding reasons are listed 
below: 

Reasons 


Talue 

1 

2 

3 

8 

9 

16 

IT 


Header block check error 
Tata field block check error 
REP response 

Buffer Temporarily unavailable 
Receiver overrun 
Message too long 
Message header format error. 


(3) The RESP field is the same as the RESP field of ACK and 
data messages, and in NAK it usually implies some arror in the message 
with number EESP+1 (mod. 25 S) or beyond. 

(iii) REP (Reply to Message Number) : This message is sent to 
enquire about the status of a previously sent message and is usually 
sent when an ACK or NAK is not received within a timeout period. The 


reply to a REP is an ACK or a NAK depending on whether the receiving 
station has received all messages previously sent. The format of a 
REP is shown in Figure 3-1 (d)« The ENQ, FLAGS, ATTR and BLKCK3 are 
the same as in other control messages. 



(1 ) EEPTIPE (l byte ) s This field indicates the type HEP and . 
has a value of 3 . 

(2) BEPSUB (l5 hits') ? This field has a value *0* • 

( 3 ) MUM (l byte ) t This is the number of the last sequential 
numbered data message (not including retransmissions) sent by the 
transmitting station. This is compared against the number of the 
last sequential message received by the receiving station and 
results in an ACK if they agree and in a NAK otherwise. 

(iv) STBT (Start Message) : This message along with STACK is 
used for protocol initialization and its function will be described 

in detail under ’start up procedure’ in Section 3 “ 3 * 

Its format is shown in Figure 3~1 (e) ♦ The EHQ, ADDR and BIKCK3 
fields are the same as in other control messages. 

(l ) STBITYPE (l byte) : This indicates the type STRT and has a 
value 6 . 

( 2 ) STHTSUB (6 bits) : This field has a value ’O’. 

( 3 ) Flags (2 bits) ; Those flags have the same function as in 
other messages but both flags are ones for STBT message. 

( 4 ) FHLi These 2 FILL bytes have a value of \0 % . 

(v) STAGE (Start Acknowledgement Message This message is sent 
as a response to STBT during initialization* Its format is shown in 
Figure. 3-1 (f). ENQ,, FLAGS, FILL, FILL, ABLE and BIKCK3 fields are 
same as in STBT. 

(1 ) smsrmw (1 byte) i Indicates STACK type and has value ’7’ * 

( 2 ) STCKST3B (6 bits): Has a value of ’0*. 



3-1 «3 Maintenance -Mess absces s The DDGMP protocol operates in 
two "basic modes: (l ) On line on normal running mode, ( 2 ) Off line 
or the maintenance mode- The previous messages correspond to the 
on line mode- The maintenance mode may be used for basic diagnostic 
testing and simple operating procedures such as bootstrapping, 
down line loading and dumping- It provides a basic envelope com- 
patible with DDCMP framing, link management and ORC check for bit 
errors but does not include any error recovery, time outs or 
sequence checks- 

The format of a maintenance message is shown in Figure 3“1 (g) * 

0 ) DIE (1 byte) : This field identifies a maintenance massage 
and has the value I44(220g)- 

(2) QOUHT (14 bits) : This field specifies the number of 8 bit- 
bytes in the DATA field. The value '0 ! is not allowed* 

( 3 ) FLAGS (2 bits) : Both these flags have value *1** 

(4) FILL ; These 2 fill bytes have a value of ‘O 1 - 

( 5 ) ADDR (l byte) : Same as for other messages* 

( 6 ) BLKCK1 (2 bytes) : CRC check hytas for the header* 

( 7 ) DATA (‘COURT* Ho. of bytes): This is the data field ana 
contains number of data bytes specified in the COURT field* 

( 8 ) BLKGK2 (2 bytes): CRO check on the data 
3-2. OPERATION OF DDGMP 

The functions of DDGMP can be grouped under three heads: 

(l ) Framing 

i2) Link Management 

( 3 ) Message Exchange 

These are discussed in the following subsections* 
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3~2.1 FR/JrIIITG ; Framing is the process of locating the 
beginning and end of a message at the receiving end* Fox this, 
the receiving end must synchronise at the bit, byte and message 
levels. We shall describe how DiCMP accomplishes these functions. 

("* ) Bit Synchronization : This function is achieved by the 
hardware interfaces (or modems) and is not a port of DDCMP. 

(2) Byte Synchronization: lata is sent over the line as a 
sequence of bits grouped into 8-bit bytes. The receiver must 
bo able to locate the proper 8 bit window in the bit stream arid 
stay in step with it for every subsequent 8 bit grouping. On a 
synchronous line, this function is accomplished by searching for a 
unique byte called a SYInT byte (value 226 g) . Once this is found 
every subsequent group of 8 bits forms a byte . 

TODGMP specifies that the receiver must locate and lock on to 2 
consecutive SIU bytes to achieve byte synchronization. The trans- 
mitter must send four or more SYTT bytes to allow for tho loss from 
missynchronization and hardware interface constraints. 

After the re coition of a message, two possibilities exist: 

(i) The next message immediately follows the current message. 

In this case the receiver will remain synchronized and reception next 
of the message will continue. 

(ii) The next message does not immediately follow this message. 

In this case , byte synchronization is assumed to be lost and the 
receiver must resynchronize for receiving the next message.- - 
Benoe the next message must be preceded by a synchronization sequence 
(i«e.» 4 of more SIU bytes). 



On sohq comunpation interfaces like the IMA type, the 
received data nay be buffered in the device hnd by the time 
the software driver cones to know that the next message is not 
contiguous, the device nay have buffered many bytes further ahead 
on the link. So, a long synchronisation sequence is required in 
such cases to account for potential buffering in tho interface* 

The length of the SY2T sequence should be 4 more than the number 
of bytes buffered. A value of 8 is generally suitable* 

To reduce the length of the synchronization sequence, the 
QSYNG flag is used (‘This is one of the link flags described in 
Section 3—1 *1 ) • When this flag is *1’, it notifies the receiver 
that the next message will not be contiguous to the current one 
and the synchronization sequence preceding that message nay be 
the short sequence. So, on seeing a QSYNC flag the software 
driver at tho receiver can start re synchronizing immediately after 
the current message without looking ahead into the next message, 
thus enabling the receiver to synchronize on a short sequence* 

( 3 ) Message Synchronization : The beginning of a message is 
located by searching for one of the three bytes SOH, ENQ, and DIE 
(which are the starting bytes of data, control and maintenance 
massages respectively, as described in Section 3“1 ) • On® of these 
bytes must appear immediately after the SIN sequence or immediately 
after the previous message's last byte. Otherwise, the byte synchro- 
nization is assumed to be lost. After detecting the first byte, the 
end of the massage is determined by the following rules* 



(1 ) If the starting "byte is SOH or DIE then the next 5 'bytes 
will complete the message header, followed hy 2 "bytes of CRC check 
on header followed by 'COUNT* number of bytes of data followed, by 
2 bytes of data block chock. (See Section 3-0* 

(2) If the starting byte is E1Q, then the next 5 bytes will 
complete the massage followed by 2 bytes of CRC check. 

Since no pattern searching is done once the starting byte is 
found, the data field is totally transparent. 

The receiver tries to achieve message synchronization only under 
the following conditions! 

(l ) Initially on start up 

\ 2 ) If messages are not contiguous 

(3) If the QSYNC flag is set in the current message, resyn- 
chronization is done at the end of this message. 

(4) If CRC error or other error occurs that might have caused 
synchronization to be lost. 

In a sample implementation, synchronization may be done after 
every message, but this is somewhat less efficient. 

3-2.2 Link Management ! The SELECT flag in all the messages is 
meant for link management, i.e., controlling the transmission ownership 
on half duplex and multipoint lines. However, in the case of full 
duplex point to point lines , there is no link management required. 

In this case the address field is kept *1 * and the SELECT flag has 
no role to play. We shall not discuss this component of EDCMP since in 
our implementation only point to point full duplex links are involved. 

3-2 .3 Message Exchange: This component of DDCMP caters for the 
exchange of error-free and correctly sequenced data messages. The 
following is a description of this component of DDCMP. 


(l ) The transmitter assigns the next sequential massage 
number n to the data message, adds a CRC "block check and sends 
it- After sending a message, a timer is started. 

(2) The receiver, after receiving the message, checks it for 
any errors and compares the message number with the next expected 
and takes the following actions* 

(i) If the number is correct a positive acknowledgement 
(ACK) carrying this number is sent back and the next 
expected number .is incremented modulo 256. 

(ii) If the message is in error, a negative acknowledgement 
with error reason is sont. The NAK also carries with 
it the number of the last correctly sequenced message 
received- HAK is sent to hasten the process of re- 
transmission, without waiting for a time out. A NAK 
not only indicates an error, but also acknowledges the 
correct reception of messages upto the number carried 
by it. 

(iii) If the message is correct but its number is not equal 
to the expected message number, it is simply ignored- 

(5) The transmitter follows the following procedure: 

(i) If it receives a positive acknowledgement, it compares 
its number with the one expected- If it agrees, the 
message is released, the user is notified and the timer 
is stopped- If the acknowledgement number does not 
agree with the expected number, it is ignored- 

(ii) If it receives nothing and a timer expires, it sends 
an" enquiry massage called ESP to the receiver with the 
number of the message previously sent. The response to 
a IMP is an ACK or a NJK depending on whether the 
message with ’that number was correctly received or not. 
The transmitter timer is again started after sending 

a HEP ani if it expires again, this process is repeated- 
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•often sons specified number of timeouts, the user is 
informed, who nay decide that the link is out of service* 

The following points nay be noted about this procedure: 

(1 ) The transmitter can send upto 255 messages without waiting 
for their AGKs* An AC K confirms the correct reception of all messages 
between the last acknowledged message and the one with the number 
contained in this ACK* Same is the case for a HAK* If an ACE gets 
corrupted, the information lost in it is automatically included in a 
subsequent ACK, thus eliminating the sending of EBP messages if the 
ACEs are received prior to the expiration of the transmitter timer* 

(2) An M K need not be sent separately, but can be piggybacked 
with a message going in that direction (the EESP field contains 
the ACE number)* 

3-2*4 Message Exchange Variables : The following variables are 
used in the message excharge state tables. Arithmetic operations and 
comparisons for those variables are always modulo 256. 

(1 ) N: It is the number of the highest sequential 
data message transmitted by this station. It is 
sent in the MM field of EEP messages. 

(2) R: The number of the highest sequential data message 
received at this station* Sent in the EESP field of 
data messages, ACEs and NAKs. 

(3) A: The number of the highest sequential data message 
that has been acknowledges to this station* 

(4) T: It is the number of the next data message to be trans- 
mitted* YVhan sending a new data message, T will h ewe the 
value N+1 • v?hen retransmitting, T will be set to A+1 and 
will advance to 11+1 . 

(5) X: The number of the last data message that has completed 
Transmission* 







3-2*5 Control Flag Variables : There are three control flags 
which specify the sending of control messages. 

(l ) SACK (Send A CK Flag) : This flag is set when either R is 
incremented (i*e*, a new data message has been received) or a ESP 
message is received which requires an ACK reply. It is cleared, when 
a DATA message is sent with a piggybacked ACK, an ACK message 
is 3ent or the SNACK flag is set • 

(2) ME (Send NAK flog)* This flag is set when an erroneous 
message requiring a NAK reply is received. It is cleared when a 
NAK is sent or when SACK is set. 

(3) KBP (Send SEP flcg)j This flag is set when a reply timer 
expires in the running state indicating that a EBP should be sent. 
3-3* DDCMP STATES AND THE START IIP PROCEDURE 

DDCMP oan be in one of the following states: 

(1 ) HALTED: This state signifies that the protocol is not 
running* 

(2) START INC : This means that an attempt is being made to 

initialize the protocol. This state has two internal states, 

ISTRT and ASTBT, the details of which will be soon made clear* 

of 

(3) RUNNING- : This is the on line state^DDCMP in which numbered 
data messages are exchanged » 

(4) MAINTENANCE : This is the off line state of DDCMP in which 
maintenance massages are exchanged* 
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Pron the halted, state, protocol initialization begins when 
a start up command is given by the user, in exchange of STRT- 
STACK ness ages takes place and state transitions taka place fron 
HALTED to HOMING via ISTRT and J±STRT. These transitions are 


depicted in the state diagram shown in Figure 3-2. 

3-4* ?HE MG STATE AND D AIA TRANSFER 

It i3 the RUNNING state in which nunbered data messages are 
exchangpd, acknowle dgeme nt s sent, retransmissions done and all 
similar actions taken. Following is a table showing various 
events and corresponding actions in the RUNNING state. ITote 
that all conparisions are modulo 256 . 'The priority of transmission 


is given ass NAK, EBP, data message, ACK. 


Event 


Action 


•Receive data message (lTOII=R+1 ) 
. Be oe ive d at a me s s age (NUM^R+1 ) 
•Receive message with errors 
.Receive HEP (NIM=R) 

•Receive REP (NTM^R) 


.Receive ACK or data message 
with AdffiSP. ^N 


•Receive ACK or data message 
with EESP 4 A or HESP > I 

.Receive NAK with A ^ Resp^ H 


Give massage to user, set SACK flag. 
Ignore 

SET S1TAK flag" with appropriate reason 
SET SACK 

SET SNAK, raaacsa 3* 

For all messages (a<NIM $RESP), 
notify user of their receipt and 
release them. 

A t— ®SP 

If T 4 A, then A+1 
If A a X, start timer 
If A ^ X, stop timer 

Ignore 

For all messages with A % HIM ^ Rasp 
inform user of their reception, 
AA—Resp 
T <.— A+1 
Stop timer 
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.Receive HAK ’ with KEEP. %k 
or Rasp v 11 

Ignore 


•Timer expires 

Set SHEP flag 


•Transmitter idle, SMK sat 

Send HAK, Clear SMK. 


•Transmitter idle, SNAK 
clear, SHED? set 

Send HEP, clear SEEP. 


•Transmitter idle, S3MK 
and SHEP clear T ( 11+1 

Retransmit message T, 
Cle ar SACK. ' 

T <— T+1 , 

•User requests message to be 
sent, T=N+1 , Transmitter 
idle, SftfiK and SEEP clear 

Send message with number if+1 , N -^H+l , 
T <— 1+1 

Cle ar SACK 

•Transmitter idle, HAgf and 
SHEP clear, Ho user request 
waiting, SACK set 

Send ACK 

Clear SACK. 


•Data Message (num) transmi- 
ssion completed on link 

X£— FOM 

If A <_X and timer not 
timer 

If A >>X, stop timer 

running start 


.HEP message transmission com- Start timer 
pie tod on link 


Not© : (l ) The term ' send * used above means put the message in a 
transmitter queue. 

( 2 ) The term 'transmitter idle' above means that queuing 
space for transmission is available. 



CHAPTER 4 

niPIElEHTAPIOI OP DDCMP OK MICRO-78 

DDCMP was described in detail in Oh apt 01 3* Row , we shall 
discuss its implement at ion on MICRO-78* Since the MIGRO-78 is 
linked with thiGo computers, i*o*, DEG-1 090, IBM-1800 and TIC-316, 
we require three different implementations of ID CMP on it, one 
for each link* However, tho Basic structure of all the three 
inplciiG nt at ion s is identical and the differences lie only in some 
finer details, which will ho nado clear when wo discuss those 
details* First wc shall discuss the "basic structure of the imple- 
mentations* 

4-1 * BASIC STRUCTURE 

There are six basic routines, viz*, the transmitter interrupt' 
routine, the receiver interrupt routine, tho DDCMP receive routine 
(iDR), tho user transmit routine (ISEKD) and the user receiver (USRCV) 
routine* These routines are interfaced hy various queues os shown 
in Figure 4-1 • The functions of each of these routines are briefly 
described below* 

(l) USENDs This is the user’s routine and is used to pass • 
on messages and commands to DDCMP* Whenever the user wants to 
send a message or give some command (startup, halt, etc*) he 
takes a free buffer from FREQ,, which is a pool (queue) of free 
buffers, puts his mess age/ conn end in that buffer and places it in 
a queue , Q1 * 
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(2) EDTs This routine is a component of PD CMP that is 
responsible f on tho transmission cepe ct . This routine decides 
what has to be transmitted next, i*e*, whether a control message 
a now data message or cm old data message should bo sent next* 

It alsb checks up whether thoro is any halt or startup message 
in 0,1 . Accordingly, it takes appropriate action, i.e., halt ing 
the protocol or sending the next message aftor proper formatting of 
header, CRC, etc# The messages to be sent are placed in a queue Q2* 

(3) Transmitter Interrupt; Routine : This routine takes messages 
one by one from 02 and sends then on the link* After a complete 
message has been sent, this routine also takes some other actions 

like starting a timer, stopping a timer etc* If a control message 

*CT*L 

has been sont, its buffer is returned toJSBBSj, but if a data mossago 
has been sont, it is plaood in QU» the queue of unacknowledged 
messages* 

( 4 ) Receiver Interrupt Routine * This routine is responsible 
for receiving messages from the lino and pla-cing them in the queue 03 • 
It basically performs the function of message framing* 

(5) DDR t This routine is the receiving component of DDCMP* 

It takes nossagos from 03> examines them, checks their CRC block 
chocks and accordingly takes appropriate actions* The* correct data 
messages are plaood in a queue 04 for the user* 

(6) TJSRCV ; This is a user f s routine that takes messages one by 
one from 04 an d uses them appropriately. The freed buffers are sont 




4-2. SPE CIAL F EMBUSES OF THE BfflEElMION 

Due to some peculiarities of the hardware interfaces, certain 
special features had to he introduced in the implementation of DDCMP, 
which a, re discussed in the following subsections. 

4-2.1 Special Features of Implementation on IBM-1800 Side s 

(i) Although DDCMP spocifies that the receiving end should 
synchronize only after the roce ption of two consecutive SYN charac- 
ters, our interface synchronizes after receiving just ono character. 
Moreover, the value of the SYN character is 026 Q instead of 22 6g as 
specified by the protocol. 

(ii) The hardware interface recognizes the character 001 Q as the 
starting character of any message and an interrupt is gonerated when 
this character is received. However, in DDCMP we hove 3 starting 
characters, S0H(201g), BNQ(OQ5 8 ), DLE(220g). So, m precede every 
message with the character 001 Q « This satisfies the purpose of 
implementing DDOMP without making any hardware changes. 

(iii) We re synchronize after every nossrge. At least 2 SIDs are 

sent before ary message* Consequently the flog QSYHC is not used 

) 

in the implementation. 

(iv) A filler byte (SYN) is sant/reoeived after the first character 
(SOM) in any message. It is only after the filler byte that the 
header of anossago starts. This is done because on IBM-1800 side, 
wo have got only word operations (one word = 16 bits). 



4-2.2 Spaoial Features of Implementation on the TDC-^I 6 Side : 


There are three special features of the implement at ion on the TDC-Jl 6 
side and they are identical to the features (i), (ii) and (iii) des- 
cribed in Section 4-2 .1 « 

4-2.3 Special Features cf Implementation on the SEC-10 Side ; 

(i) On 3E0-10 side, the value of the SY1T character is 22 6q as 
against the value 026^ used on other links. This value conforms 
to the HDCMP specifications • However, we synchronize after detecting 
just i SHI character. 

(ii) Th6 message sent/ro GQived on the MICBQ to 3EC side is a 
standard TDCMP message, without having any other character (like SQvI 
in other 2 cases) preceding it. 

(iii) vThile sending a nessago, a sequence of at least 4 SHTs is 
sent procoding the nossnge* So QSYNC flag is of no concern while 
sending a message. However, when a message is received, QSYNC is 
checked and appropriate action taken • 

In tho following sections m shall discuss the implementation 
of DDCMP for the MICRO-78 to IB1-1800 link. The implementations 
for tho other two links will be different only in the special 
features discussed in Section 4~2 and no separate discussion is 
needed for them. 

4-3. BUFFER FOmiifTIHG ASP QUEUES 

BuffGr3 aro arranged as doubly linked lists. Every list has 
a header which occupies 5 bytes in tho format shown in Figure 4-2(a). 

The buffers for transmitting or receiving messages have the 
format shown in Figure 4-2 (b). It should be noted that tho field 
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’message number* 
The field 'type* 
Value 


0 
1 
2 

3 

6 

7 

99 

4-4* jjgEfc VARIABLES AND CONTROL ' FLAGS 

is already described in Chapter 3* various data variables 
R,T,N,A,X and control flags SACK, SNAK and SHSP are required for 
DDCMP implementation. Besides, another variable indicating the 
state of DDCMP is also thore* This variable ( STATS) has got the 
following interpretation* 

Value. State of DDCMP 

0 ISTBT 

1 ASTBT 

2 HOMING 

3 HALTED 

4 ■ MAIMSNANGE 

4-5* ROUTINES FOB QUEUE OPERATIONS 


is relevant only in the case of data messages. 

is interpreted as follows: 

Moaning 

Data message 
ACK nos sago 
NAK message 
HEP message 

STEP message (Also serves the purpose of ’start 
protocol’ command from the user) 

STACK message 

HALT command (Prom user to DDCMP) 


t 


There ora four routines for various queue operations* These 
routines nay be called by any other routine which needs to perform 
operation on the queues. These routines are: 

(l ) SHFTQ : This routine shifts a buffer from one queue to another, 
i*e#, it removes the first buffer of one queue and appends it to the 
ond of another queue. The address of the header of the queue from 
which a buffer has to bo removed must be placed in H and L registers 



and the address of the header of the queue to which this "buffer 
will he shifted nust be placed in D and E registers before calling 
this routine* Its calling sequence is 

CALL SBFTQ 

SHFTQ should be called only when the queue fron which a buffer is 
to be shifted is non-empty, otherwise a fatal error is assumed to 
have occurred and the protocol halts after printing an error message 
(lief * Appendix . 1 ) « 

a 

( 2 ) SRCHQ ; This routine searches ,/list for a buffer with a 
particular message number (i*e • , a particular value in the IT® field* 
Ref. Figure 4-2 (b)) and £fter finding that buffer, removes it from 
the original list and places it at the end of another list. It is 
essential that the address of the header of the queue in which the 
buffer i3 to be searched and removed be kept in the H and L registers 
the address of the header of the queue to which this buffer will be 
shifted to be placed in I) and E registers and the number of the 
message bG kept in the location called 1 SHIM’ before the routine is 
called* Its calling sequence is 

CALL SRCHQ. 

If the search succeeds, a flag SHE® is set, otherwise it is 
reset. The calling routine should examine SRERR and take appropriate 
action* 

(3) EUPTQ, : This routine shifts all the buffers of one queue 
to another queue. The address of the header of the queue from which 
n.*n the buffers have to be removed must be placed in H and L register 




and. the address of the header of the queue to which all these 
huffers will he shifted to oust he placed in 13 and E registers 
before calling this routine. Its calling sequence is 

GAEL EMPTQ 

The queue fron which all the buffers have to he shifted out 
nay he enpty. 

a 

(4) SRCQ2 : This routine searches^List for a buffer with a 
particular message number and after finding that buffer, sets the 
SUEUR flag and if the search fails this flag is reset. The address 
of the header of the queue in which this buffer is looked for must 
bo placed in H and. L registers and the message number must be 
placed in SEIM location before calling this routine. Its calling 
sequence is 

CilLL SECQ2* 

4-6. HffillED EXPLiihlTIOE OF VARIOUS ROUTIEES 

(l ) USBKD i This routine takes an empty buffer from FREQ, 
a 

and places it in/tenporary queue TEMQ* and fills it as follows: 

(i) If the user wants to give a command which will halt the 
protocol after sending all the previously given messages he places 
number 99 in the 'type* field. 

(ii) If the user wants to give a start up oomnand, he places 
Ho. 6 in the type* field. 

*TEMQ is another queue which is used to hold a buffer temporarily 
while it is being processed by some routine. This queue never 
contains more than one buffer. . 



(iii) If the "use i wants to send a data message, he places n~* 

’O’ in the type field, the number of <3 ata bytes in the COUNT field 
and the data in the data field* After the buffer has been filled 
with relevant information it is shifted from TEMQ, to Q! • 

If -the user wishes to halt the protocol immediately (i»e., 
even before the previous messages are transmitted), he simply 
sets a flag called SHALT. 

(2) DDT ; The basic function of this routine has already been 
explained* The details, are clear from the flowchart given in Figure 
4-3 (a) . The following points will help in understanding the flowcharts. 

(i) There are six header routines, LIES, AGK, NAK, HEP, STBS and 
STACK (Figures 4~4(a) to (f)), which generate the head®* for that 
message type. These routines fill in all the information shown in the 
transmitting side buffers (Figures 4“2(b) ) except tho data in data 
massages and tho CRC chock on the data. Those routines need only 

one parameter to bo passed, i.e», the address of the header of that 
queue which contains the buffer to be filled in at the front* 

(ii) All arithmetic and comparison operations shown are modulo 256. 

(iii) A routine for CRC generation is called at various points. 

Before calling this routine, the address of the first location contain- 
ing the data on which CRC is to be gonerated/checked should be placed 
in registers H and L,the count of data bytes should be placed in 
registers B and C and a location FLAG- should be set to 0 or 1 depending 
on whether CRC generation or checking is required. When this routine 
is called for CRC generation (FLAG = 0) two CRC check bytes are 
placed in two locations immediately following the data. When it - 
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is called f or CRG check; (FLAG = 1 ) , the variable FLAG is set to 
0 if no error is detected, otherwise at remains 1* 

( 3 ) Transmitter Interrupt Routine ? in interrupt is generated 
after the transmission of every byte of a message* The interrupt 
routine initiates the transmission of the next byte, if any* When 
all the bytes of a message have been transmitted, certain actions 
are p rf ormed as are clc ar from the f lov?ohart given in Figure 4“5 ft 
However, this routine has not been coded and tested because the 
hardware interfaces are still being fabricated* 

( 4 ) Re ce ive r Int e rrupt Rout ine : 'When an SOM character is 
detected by the interface in idle mode, a hardware mode bit is 
sot and an interrupt is generated* For Gvery subsequent byte 
received while the mode bit is on, an interrupt is generated* 

This continues till the entire message has been received and 
after that the mode bit is reset by the interrupt routine* The 
functions performed by the interrupt routine are clear from the 
±' lav chart in Figure This routine has also not been coded 

and tested* 

( 5 ) DDR* The flowcharts of this routine and those of ACKR 
and HAKE (Figures 4~6(a) to (c)) explain the functions performed 
by DDR* 

(6) USRGV s This routine takes a message from Q4» makes it 
available to the user for processing and returns the freed buffer 
to FREQ* 
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4-7. TIMER AND ITS ROUTINE 

As goon as a data message or a HEP is transmitted on the 
link in ROUTING state, or a STACK or STRT is transmitted during 
the STARTING state, a timer is started and after a selected time 
interval an interrupt, is generated if no AGK or NAK is received 
dur ing this interval. The timer interval can he selected by 
as s i gning a value to a variable TH.WAL* This value is calculated 
by the formula 

. , , » / Interval Required N 

TIM7AL * 2's complement of (. Tic]Q ta3Q use d ' 

The timer interrupt routine examines .the STATE of DDGHP and 
takes appropriate actions as shown in Figure 4“7» 




fig, 4.7 ; timer routine 
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CHAPTER 5 
C0UGLFSI0H 

Our aim during the current phase was to implement the lowest 
layer protocol on IBM-1800 and MICRO-78 iand design the hardware 
interfaces for the MICRO to BBC link. Since DDCMP was the line 
protocol used by DEC and its implementation was available on the 
system, this protocol was chosen for our network and to implemen- 
ted it on MICRO-78 and IBM-1900. The hardware interfaces designed 
were found flexible enough to support DDCMP without much problems. 
However, some other problems were discovered in the design of 
these interfaces and suitable changes have been made to solve 
these problems. Moreover, the hardware interfaces of MICRO-78 
and TDC-31 6 though tested gave frequent problems because their 
fabrication was not very neat and are therefore being refabricated 
by a professional. The interfaces of IBM-1800 are, however, in a 
working condition and DDCMP has been tested on Mhsmia a loop back 
mode. On MICRO-78 also, DDCMP has been implemented and tested 
except for the interrupt routines. 

The design of the MICRO to DEC interfaces had to monform to 
the DQ11 specifications and so it is somewhat different from the 
other interfaces in the network. 

As soon as the hardware interfaces of MICRO-78 and TDC— 316 
are refabricated-lDDCMP can be tested on the IBM— 1800. "MICRO— 78** 
DEC-10 link and subsequently, higher level protocols can be 
implemented to provide network facilities between IBM 1800 and 



and EEC-1 0 « For TDC~31 6, the software is already available , and 
wa do not foresee any problems in connecting it to the network* 

Since the hardware interfaces on IBM-1800, TDC- 3 I 6 and 
MICBO -78 (except the MICRO to EEC side interfaces) were designed 
before the digital network specifications wre available, their 
design included some features which should now be changed* One 
change that should be made is to remove the parity generation 
and die eking circuits from these interfaces, since the DQ-11 
interface of DEC-10 does not include this feature* Moreover, 
if any errors do creep in, they are taken care of by the CRC block 
checks specified in DDCMP* Presently, the CRC generation and checks 

are performed by software routines, which cause a lot of overhead* 

To remove this overhead, it is desirable that hardware chips are 
used to do this work, Another inconsistency between the DDCMP 
specifications and the earlier hardware interfaces is that the 
value of SY1T character used on the MICRO -78 links to TDC- 31 6 and 
IBM-1800 is 026g as. against the value 22 6 g specified by DDGMP* 

This inconsistency can easily be removed by making minor hardware 
changes* 

To increase the data transmission rates, it is suggested 
that DMA interfaces he used for data transmission and reception* 
This is particularly essential on the MICEO- 78 * Another suggestion 
is that provision be made for varying the baud rate on the links* 



APPENDIX I 


ERROR MESSAGES 


While performing queue operations, two types of fatal errors 

may be detected and when these errors occur, the system comes to 

a halt after printing same error messages. DDCMP must be reloaded 

when these errors occur* The error messages are; 

(1 ) 'ATTEMPT TO SHIFT FROM All EMPTY Q. FATAL ERROR 
J1ELOAD SYSTEM.’ 

This message means that at some stage an attempt was made to take 
a buffer from some queue which was already empty. 

(2) . * SRCHQ, FAILED • FATAL ERROR RELOAD SYSTEM’ . 

This message means that a buffer was not found in a list when a 
search was being made for it* 



APPENDIX II 


OPTIONS USED IN DQ11 


The DQ11 is a high speed, double buffered communications 
device designed to interface the PDP-11 processor to a serial 
synchronous communications channel. Transmit and receive data 
transfers between the PDP-11 Unibus and the DQ11 are handled as 
non processor requests (NPRs). As an NPR devioe, the DQ11 pro- 
vides extremely fast access to the PDP-11 unibus. 

For a detailed description of DQ11 , Ref. 3 may be seen. 

Be shall give here the options on DQ,11 chosen by us. 

(1 ) Transmission speed - 10K bauds 

(2) Pull duplex operation 

( 3 ) No parity 

( 4 ) 'Pwo SYN characters (226g, 226g) 

( 5 ) Character size of 8 bits ° 

(6) The three switch selectable control characters 
for program interrupts are 201 g, 005 Q and 220g* 

( 7 ) ORC check using the polynomial x - ^ +°x15 + x 2 + 1 * 

(8) No modem used 

( 9 ) For reception and transmission external clock is 
used. This clock comes from the MICRO -78 inter- 
face on a separate line. 

(10) Interfacing is done in EIAmode. 
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